👀

Would you be able to rebase this PR, mostly to get a nicer view of this PR against the rebased 6.17.y branch?

Also, is there any semi-official word from Pi Towers if this has a chance of merging? It's certainly been stable for me across multiple iterations of testing on multiple generations of AMD and Intel GPUs...

Also, is there any semi-official word from Pi Towers if this has a chance of merging?

I don't think we want this to be in the pi tree but not in the upstream tree.
That creates a lot of pain with merge conflicts.

Ideally any "correct" commits here should be submitted upstream.
We are generally happy to backport commits that have been accepted upstream to get them sooner.

I need to tidy up the branch.

AMD GPUs only need 70fe325 and the defconfig update.
I want to understand that first commit a little more as I'm not getting what the change in ttm_bo_util.c is doing for us. Actually I think it can again be reduced to a #ifdef CONFIG_ARM64 around the first if clause which is going to be less painful. If I understand it, then I can make the case upstream. They may want it under a dedicated Kconfig option rather than just CONFIG_ARM64, but that's still not a deal breaker.

Module size for amdgpu is 2.5MB. I haven't tested with 16kB page sizes, so it may only apply to bcm2711_defconfig and not bcm2712_defconfig.

We could add in radeon for the older cards (module size is 466kB), but it won't work with labwc / wlroots as the DRM driver doesn't support atomic updates.

Intel Xe isn't quite there yet, and the places it calls into i915 are annoying. Easiest to drop it for now. The i915 changes were proposed by Mesa devs so may be acceptable to mainline. The BAR resizing patch is already being discussed upstream and has been looked at by P33M. (Module size is 814kB).

nouveau is a fair way off, so that can just be dropped for now. (Module size is 632kB).

Branch cleaned to have the minimal changes (6 lines) required to support AMD gpus (either amdgpu or radeon). Other cards are dropped.

I'll try to find a few mins to propose these upstream in the next few days.

@6by9 last night I was thinking about it — and indeed, the Intel changes, while simpler, need more time in the oven. It would be nice to get full AMD support, and it seems like the changes shouldn't be hard to make a case for.

Until we get the Xe driver past the weird corrupt/glitchy graphics bug, it's fine having it separate. I'm still working on getting someone on the Intel driver side to take a look, it may be something simple!

BTW I've created https://github.com/6by9/linux/tree/rpi-6.18.y-pcie-gpu with both the AMD and Intel changes in.
6.18 is only on rc2, so pretty early days but most things are working.

@6by9 - I was thinking it would be nice to have a PR open on this repo for the convenience of users who want to just do an rpi-update to it (instead of a full kernel recompile). If I create and maintain a PR will it still trigger the same build process as yours? Or would updating it every few weeks or once a month create any undue burden on the RPi CI infrastructure?

Just wanting to make it easier for people to test, since recompiling the kernel is a step too far for some.

I've also just found and responded to a similar Intel patch on the kernel mailing list: https://lore.kernel.org/lkml/[email protected]/

Looks like that's been sent from the RISC-V side of things (they're also affected).

#7113 for a 6.18 kernel with AMD and Xe enabled. I'll try to remember to bump it every so often. (Just bumped this 6.17 branch).

There are a couple of issues with 6.18 that are still to be worked through, so use with caution. 6.17 should be fairly stable.

Anyone can create a PR. Contributors without a couple of merged PRs require manual triggering to run the CI workflows.
Github workflows running on x86 or ARM Linux are free for public repos :-)

Thanks! And for tracking, could you change the title of this one to maybe say Testing AMD PCIe graphics cards on Pi 5 since it's more targeted at that now? (Or something to help differentiate when searching)

Thanks! And for tracking, could you change the title of this one to maybe say Testing AMD PCIe graphics cards on Pi 5 since it's more targeted at that now? (Or something to help differentiate when searching)

Subjects updated to include the kernel version targeted, and which cards they cover.

Just tested on a fresh install today: Using AMD GPUs on Raspberry Pi without recompiling Linux

Posting the instructions here since I realized they're not listed in the comments anywhere:

sudo rpi-update pulls/7072

Then edit /boot/firmware/config.txt:

dtparam=pciex1_gen=3  # for faster PCIe Gen 3 speeds on Pi 5
auto_initramfs=0  # to avoid 'weird boot mechanisms or file systems'

Then install AMD firmware:

sudo apt install -y firmware-amd-graphics

The AI Pro R9700 worked out of the box with that. Very nice!

Do you have any idea of the patch could be upstreamed into Linux as-is? Or any other changes required?

Branch rebased.

Do you have any idea of the patch could be upstreamed into Linux as-is? Or any other changes required?

It's only the "drm/ttm: Use dmacoherent allocations on ARM64" patch that needs to be upstreamed.

Switching on CONFIG_ARM64 is incorrect as some ARM64 platforms have cache-snooping PCIe controllers, so there is a question as to what the appropriate thing to switch on is. It's probably adding some other Kconfig option that conditionally enables this behaviour, but I have no feel as to whether that should be an architecture level config, or a DRM_TTM one.

I'm afraid I haven't time at present to drive it forward with upstream :-(